In data access systems, often records are being accessed, modified, deleted, and added by various personnel on a daily or even hourly basis. In large organizations there could be hundreds of people accessing various records and changing them from time to time. It is important however, that security policies be enforced. For example, due to the potential for fraud and embezzlement, it is important that two or more people be involved in the total implementation of certain processes. Such a separation of duties policy reduces the potential for fraud because it requires that multiple people would have to conspire with each other in order to implement a dishonest transaction. Consider a record in a database created which reflects the ordering of a particular item. The company will incur a cost for such item, and approval is required. A record would be created in the database reflecting the order.
When payment is made, it is preferable that a different entity be responsible for signing the check and making payment. This precludes the ordering entity from ordering items that should not be ordered. Thus, in order to draft and sign the check for payment for the order, an additional entity should be involved. This additional entity means that for someone to order and pay for goods for a particular purchase, at least two parties would have to be involved in any potential fraud. This greatly decreases the possibility of such fraud occurring.
An example of another kind of security policy is conflict of interest, specifically a ‘Chinese Wall Policy’. This policy prevents an analyst who is consulting for company A from accessing potentially sensitive information on company B, a competitor of company A, thus preventing the analyst from providing company A with confidential information about company B (or making recommendations to company A based on this confidential information). Separation of duties is considered to be an integrity policy while conflict of interest would be a confidentiality policy. Other security policies such as compliance to legislative regulations, and privacy are also enforced through security policies.
One prior art solution to enforcement of the separation of duties policy is to include a rule within the data access software that tests for the occurrence of a first action by a particular entity each time a specified second action is attempted. Specifically, the software simply includes a rule that if entity A is the particular entity which wrote the order, then entity A cannot process the transaction required to pay the invoice. Thus, each time an invoice payment is requested, the software would check to determine if the entity processing the invoice is the same entity that placed the order. If so, the transaction would be disallowed. Such a technique enforces a separation of duties and thereby minimizes the possibility of the occurrence of fraud.
The implementation of such an arrangement is less than perfect and is not without significant cost. First, the variety of rules regarding who can do what during specific times or with specific other conditions often leads to complex code which is difficult to modify and debug. For example, each time any action is requested, the software has to check every possible combination of prohibited transactions to determine if permitting the desired transaction would violate any rule.
Additionally, the execution time is greatly slowed by the fact that a large number of lines of code must be executed each and every time through any data access. This is extremely wasteful since, for the most part, most of the rules are not even needed unless certain other conditions apply.
An additional problem is that the separation of duties policy of prior systems is primitive in its user interface. There is little notification to users of the particular problems being encountered, and there is little flexibility in terms of changing the rules for different conditions.
Another prior art solution attaches attributes or labels to the transaction items that represent the objects on which operations require compliance with the separation of duties policy. These attributes maintain the history of operations on the object and rules are written that utilized the information contained in these attributes. The major drawback of this approach is that unless these attributes were designed into the system from the beginning, it can be prohibitively expensive to modify large legacy systems to contain and maintain the necessary attributes.
Both solutions suffer from the drawback that they only solve the separation of duties problem. Other solutions must be implemented to enforce other security policies.